home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group97a.txt / 000049_icon-group-sender _Wed Feb 26 17:15:42 1997.msg < prev    next >
Internet Message Format  |  2000-09-20  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Thu, 27 Feb 1997 09:03:41 MST
  2. To: icon-group@cs.arizona.edu
  3. Date: 26 Feb 1997 17:15:42 GMT
  4. From: espie@fregate.ens.fr (Marc Espie)
  5. Message-Id: <5f1r3u$b7l@nef.ens.fr>
  6. Organization: Ecole Normale Superieure, Paris
  7. Sender: icon-group-request@cs.arizona.edu
  8. References: <331437DE.41C67EA6@solstice.digicomp.com>
  9. Subject: Re: Icon and two-dimensional matching
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11. Status: RO
  12. Content-Length: 2405
  13.  
  14. In article <331437DE.41C67EA6@solstice.digicomp.com>,
  15. Jan Galkowski  <jan@solstice.digicomp.com> wrote:
  16. [SMALLER reply though]
  17. >[LONG post warning!]
  18. >Now, I don't in any way want to depreciate or criticize the use or
  19. >power of Icon in traditional programming.  Indeed, seeing how 
  20. >traditional problems can be addressed by new methods and 
  21. >expressive styles is crucial to developing programming itself.
  22. >While the conceptual algorithm for expression may be about the
  23. >same, the means used to realize it  with the "generate and test" mindset
  24. >available in Icon can be dramatically different than in, say, Ada.
  25. >Moreover, there are some algorithms which, because of the
  26. >availability of Icon's tables, may now be usable and practical
  27. >because the effort to use these elements is negligible compared to,
  28. >again say, Ada since their one might need to implement the
  29. >elements.  It is important to continuously reconsider putting
  30. >new wines in "old bottles" if the depth of our collective craft
  31. >is to be maintained.
  32.  
  33. Icon tables and sets are indeed a very powerful mechanism. However,
  34. they sometimes suffer from their generality. The current implementation
  35. uses hash functions that assume a rather smooth average distribution
  36. of the data. 
  37.  
  38. I've been using Icon a lot for combinatorial computations involving
  39. words, lattices and graphs, where Icon excells thanks to its 
  40. generators, and high-level operations on sets.
  41.  
  42. However, I've also ran into some spectacular failures. You see, the
  43. sets of words I study are NOT average. Indeed, I am trying to find
  44. some non obvious correlations between those... and the hashing functions...
  45. well, I've got cases where everything ended up in one or two buckets,
  46. or rather larger sets where the hashing process failed due to the
  47. sheer size of the data.
  48.  
  49. I would rather like to be able to specify MORE things about my sets
  50. (average size, distribution of data, other hashing functions) than
  51. is possible with the current implementation.
  52.  
  53. Right now, I have to reinvent the wheel, and reimplement somehow my
  54. own sets without all the clarity  Icon procures to us.
  55.  
  56. (I'll admit that Icon sets and tables works in more than 95% of
  57. the cases I've thrown at it)
  58. -- 
  59. [nosave]<http://www.eleves.ens.fr:8080/home/espie/index.html>
  60. microsoft network is EXPLICITLY forbidden to redistribute this message.
  61. `Seiza no matataki kazoe, uranau koi no yuku e.'
  62.     Marc Espie (Marc.Espie@ens.fr)
  63.